It is desired for an application using a database to improve the database performance and capacity according to the volume of data and the amount of access load. Conventionally, as a technique for improving the scalability of the entire system, there has been known a technique for creating a replica of a database and deploying multiple database servers taking care of all data onto multiple physical nodes in a distributed manner to reduce the load (for example, see Japanese Patent Application Publication No. 2001-175681. There has also been known a technique for dividing the database according to the practical search scope to deploy multiple database servers taking care of the divided partitions, respectively, in a distributed manner. Thus, the databases are deployed onto multiple physical nodes in a distributed manner to create a distributed database environment to enable improvement in transaction performance and availability and fault tolerance of the system.
FIG. 14A is a schematic diagram showing a distributed database environment in a conventional technique. A distributed database environment 500 shown in FIG. 14A includes multiple database servers 510a1 to 510c2 deployed onto multiple physical nodes in a distributed manner. In the distributed database environment 500, database partitioning and partition multiplexing are implemented so that each individual database server 510 will take care of data in a different partition or the same partition. Here, the logical unit of databases managed by a group of database servers 510 taking care of the same partition (e.g., 510a1 and 510a2) is referred to as a distributed database 520 (e.g., 520a). In other words, the distributed database 520 consists of an original database (master) taking care of the same partition and replication database (replica) replicated from the master.
As mentioned above, the database is so divided that the data range taken care of by each individual database server 510 to maintain data consistency can be reduced, and each partition is further multiplexed to distribute these database servers 510 onto multiple physical nodes so that the unit of data taken care of by each individual physical node can be reduced. This can increase the transaction performance, improving the availability and fault tolerance of the system. Further, a replica is created and data is multiplexed as mentioned above so that access load from client applications 530 can be distributed, thus improving the availability and fault tolerance of the system.
In such a distributed computing environment, a technique is generally employed, in which database servers 510 of different distributed databases 520 are combined and deployed onto a physical node 540 as the same physical resource as shown in FIG. 14B to make effective use of limited physical resources. However, when multiple database servers 510 are deployed on the same physical node 540, if access is concentrated to a database server (e.g., database A), the database server (e.g., database A) may place pressure on resources of another database server (e.g., database C′) on the same physical node (e.g., physical node 540a).
In other words, when a configuration is employed in which multiple database servers are deployed onto the same physical node, there arises the problem of a sudden overload or redundant resources. Countermeasures to this problem include a method of adding a replica of a distributed database 520 in which a sudden increase in load has been observed, a method of enhancing the physical node on which the database server 510 with the sudden load increase observed is deployed, and a method of moving the database server 510 onto another physical node having enough resources. However, in an emergency situation, such as a sudden access increasing state, since these operations themselves place heavy load, they would not be adaptive solutions.